
%% bare_conf.tex
%% V1.3
%% 2007/01/11
%% by Michael Shell
%% See:
%% http://www.michaelshell.org/
%% for current contact information.
%%
%% This is a skeleton file demonstrating the use of IEEEtran.cls
%% (requires IEEEtran.cls version 1.7 or later) with an IEEE conference paper.
%%
%% Support sites:
%% http://www.michaelshell.org/tex/ieeetran/
%% http://www.ctan.org/tex-archive/macros/latex/contrib/IEEEtran/
%% and
%% http://www.ieee.org/

%%*************************************************************************
%% Legal Notice:
%% This code is offered as-is without any warranty either expressed or
%% implied; without even the implied warranty of MERCHANTABILITY or
%% FITNESS FOR A PARTICULAR PURPOSE!
%% User assumes all risk.
%% In no event shall IEEE or any contributor to this code be liable for
%% any damages or losses, including, but not limited to, incidental,
%% consequential, or any other damages, resulting from the use or misuse
%% of any information contained here.
%%
%% All comments are the opinions of their respective authors and are not
%% necessarily endorsed by the IEEE.
%%
%% This work is distributed under the LaTeX Project Public License (LPPL)
%% ( http://www.latex-project.org/ ) version 1.3, and may be freely used,
%% distributed and modified. A copy of the LPPL, version 1.3, is included
%% in the base LaTeX documentation of all distributions of LaTeX released
%% 2003/12/01 or later.
%% Retain all contribution notices and credits.
%% ** Modified files should be clearly indicated as such, including  **
%% ** renaming them and changing author support contact information. **
%%
%% File list of work: IEEEtran.cls, IEEEtran_HOWTO.pdf, bare_adv.tex,
%%                    bare_conf.tex, bare_jrnl.tex, bare_jrnl_compsoc.tex
%%*************************************************************************

% *** Authors should verify (and, if needed, correct) their LaTeX system  ***
% *** with the testflow diagnostic prior to trusting their LaTeX platform ***
% *** with production work. IEEE's font choices can trigger bugs that do  ***
% *** not appear when using other class files.                            ***
% The testflow support page is at:
% http://www.michaelshell.org/tex/testflow/



% Note that the a4paper option is mainly intended so that authors in
% countries using A4 can easily print to A4 and see how their papers will
% look in print - the typesetting of the document will not typically be
% affected with changes in paper size (but the bottom and side margins will).
% Use the testflow package mentioned above to verify correct handling of
% both paper sizes by the user's LaTeX system.
%
% Also note that the "draftcls" or "draftclsnofoot", not "draft", option
% should be used if it is desired that the figures are to be displayed in
% draft mode.
%
\documentclass[conference]{IEEEtran}
% Add the compsoc option for Computer Society conferences.
%
% If IEEEtran.cls has not been installed into the LaTeX system files,
% manually specify the path to it like:
% \documentclass[conference]{../sty/IEEEtran}





% Some very useful LaTeX packages include:
% (uncomment the ones you want to load)


% *** MISC UTILITY PACKAGES ***
%
%\usepackage{ifpdf}
% Heiko Oberdiek's ifpdf.sty is very useful if you need conditional
% compilation based on whether the output is pdf or dvi.
% usage:
% \ifpdf
%   % pdf code
% \else
%   % dvi code
% \fi
% The latest version of ifpdf.sty can be obtained from:
% http://www.ctan.org/tex-archive/macros/latex/contrib/oberdiek/
% Also, note that IEEEtran.cls V1.7 and later provides a builtin
% \ifCLASSINFOpdf conditional that works the same way.
% When switching from latex to pdflatex and vice-versa, the compiler may
% have to be run twice to clear warning/error messages.






% *** CITATION PACKAGES ***
%
%\usepackage{cite}
% cite.sty was written by Donald Arseneau
% V1.6 and later of IEEEtran pre-defines the format of the cite.sty package
% \cite{} output to follow that of IEEE. Loading the cite package will
% result in citation numbers being automatically sorted and properly
% "compressed/ranged". e.g., [1], [9], [2], [7], [5], [6] without using
% cite.sty will become [1], [2], [5]--[7], [9] using cite.sty. cite.sty's
% \cite will automatically add leading space, if needed. Use cite.sty's
% noadjust option (cite.sty V3.8 and later) if you want to turn this off.
% cite.sty is already installed on most LaTeX systems. Be sure and use
% version 4.0 (2003-05-27) and later if using hyperref.sty. cite.sty does
% not currently provide for hyperlinked citations.
% The latest version can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/cite/
% The documentation is contained in the cite.sty file itself.






% *** GRAPHICS RELATED PACKAGES ***
%
\ifCLASSINFOpdf
  % \usepackage[pdftex]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../pdf/}{../jpeg/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.pdf,.jpeg,.png}
\else
  % or other class option (dvipsone, dvipdf, if not using dvips). graphicx
  % will default to the driver specified in the system graphics.cfg if no
  % driver is specified.
  % \usepackage[dvips]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../eps/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.eps}
\fi
% graphicx was written by David Carlisle and Sebastian Rahtz. It is
% required if you want graphics, photos, etc. graphicx.sty is already
% installed on most LaTeX systems. The latest version and documentation can
% be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/graphics/
% Another good source of documentation is "Using Imported Graphics in
% LaTeX2e" by Keith Reckdahl which can be found as epslatex.ps or
% epslatex.pdf at: http://www.ctan.org/tex-archive/info/
%
% latex, and pdflatex in dvi mode, support graphics in encapsulated
% postscript (.eps) format. pdflatex in pdf mode supports graphics
% in .pdf, .jpeg, .png and .mps (metapost) formats. Users should ensure
% that all non-photo figures use a vector format (.eps, .pdf, .mps) and
% not a bitmapped formats (.jpeg, .png). IEEE frowns on bitmapped formats
% which can result in "jaggedy"/blurry rendering of lines and letters as
% well as large increases in file sizes.
%
% You can find documentation about the pdfTeX application at:
% http://www.tug.org/applications/pdftex





% *** MATH PACKAGES ***
%
%\usepackage[cmex10]{amsmath}
% A popular package from the American Mathematical Society that provides
% many useful and powerful commands for dealing with mathematics. If using
% it, be sure to load this package with the cmex10 option to ensure that
% only type 1 fonts will utilized at all point sizes. Without this option,
% it is possible that some math symbols, particularly those within
% footnotes, will be rendered in bitmap form which will result in a
% document that can not be IEEE Xplore compliant!
%
% Also, note that the amsmath package sets \interdisplaylinepenalty to 10000
% thus preventing page breaks from occurring within multiline equations. Use:
%\interdisplaylinepenalty=2500
% after loading amsmath to restore such page breaks as IEEEtran.cls normally
% does. amsmath.sty is already installed on most LaTeX systems. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/amslatex/math/

\usepackage{amsmath}
\usepackage{amsfonts}



% *** SPECIALIZED LIST PACKAGES ***
%
%\usepackage{algorithmic}
% algorithmic.sty was written by Peter Williams and Rogerio Brito.
% This package provides an algorithmic environment fo describing algorithms.
% You can use the algorithmic environment in-text or within a figure
% environment to provide for a floating algorithm. Do NOT use the algorithm
% floating environment provided by algorithm.sty (by the same authors) or
% algorithm2e.sty (by Christophe Fiorio) as IEEE does not use dedicated
% algorithm float types and packages that provide these will not provide
% correct IEEE style captions. The latest version and documentation of
% algorithmic.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithms/
% There is also a support site at:
% http://algorithms.berlios.de/index.html
% Also of interest may be the (relatively newer and more customizable)
% algorithmicx.sty package by Szasz Janos:
% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithmicx/




% *** ALIGNMENT PACKAGES ***
%
%\usepackage{array}
% Frank Mittelbach's and David Carlisle's array.sty patches and improves
% the standard LaTeX2e array and tabular environments to provide better
% appearance and additional user controls. As the default LaTeX2e table
% generation code is lacking to the point of almost being broken with
% respect to the quality of the end results, all users are strongly
% advised to use an enhanced (at the very least that provided by array.sty)
% set of table tools. array.sty is already installed on most systems. The
% latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/tools/


%\usepackage{mdwmath}
%\usepackage{mdwtab}
% Also highly recommended is Mark Wooding's extremely powerful MDW tools,
% especially mdwmath.sty and mdwtab.sty which are used to format equations
% and tables, respectively. The MDWtools set is already installed on most
% LaTeX systems. The lastest version and documentation is available at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/mdwtools/


% IEEEtran contains the IEEEeqnarray family of commands that can be used to
% generate multiline equations as well as matrices, tables, etc., of high
% quality.


%\usepackage{eqparbox}
% Also of notable interest is Scott Pakin's eqparbox package for creating
% (automatically sized) equal width boxes - aka "natural width parboxes".
% Available at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/eqparbox/





% *** SUBFIGURE PACKAGES ***
\usepackage[tight,footnotesize]{subfigure}
% subfigure.sty was written by Steven Douglas Cochran. This package makes it
% easy to put subfigures in your figures. e.g., "Figure 1a and 1b". For IEEE
% work, it is a good idea to load it with the tight package option to reduce
% the amount of white space around the subfigures. subfigure.sty is already
% installed on most LaTeX systems. The latest version and documentation can
% be obtained at:
% http://www.ctan.org/tex-archive/obsolete/macros/latex/contrib/subfigure/
% subfigure.sty has been superceeded by subfig.sty.



%\usepackage[caption=false]{caption}
%\usepackage[font=footnotesize]{subfig}
% subfig.sty, also written by Steven Douglas Cochran, is the modern
% replacement for subfigure.sty. However, subfig.sty requires and
% automatically loads Axel Sommerfeldt's caption.sty which will override
% IEEEtran.cls handling of captions and this will result in nonIEEE style
% figure/table captions. To prevent this problem, be sure and preload
% caption.sty with its "caption=false" package option. This is will preserve
% IEEEtran.cls handing of captions. Version 1.3 (2005/06/28) and later
% (recommended due to many improvements over 1.2) of subfig.sty supports
% the caption=false option directly:
%\usepackage[caption=false,font=footnotesize]{subfig}
%
% The latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/subfig/
% The latest version and documentation of caption.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/caption/




% *** FLOAT PACKAGES ***
%
%\usepackage{fixltx2e}
% fixltx2e, the successor to the earlier fix2col.sty, was written by
% Frank Mittelbach and David Carlisle. This package corrects a few problems
% in the LaTeX2e kernel, the most notable of which is that in current
% LaTeX2e releases, the ordering of single and double column floats is not
% guaranteed to be preserved. Thus, an unpatched LaTeX2e can allow a
% single column figure to be placed prior to an earlier double column
% figure. The latest version and documentation can be found at:
% http://www.ctan.org/tex-archive/macros/latex/base/



\usepackage{stfloats}
% stfloats.sty was written by Sigitas Tolusis. This package gives LaTeX2e
% the ability to do double column floats at the bottom of the page as well
% as the top. (e.g., "\begin{figure*}[!b]" is not normally possible in
% LaTeX2e). It also provides a command:
%\fnbelowfloat
% to enable the placement of footnotes below bottom floats (the standard
% LaTeX2e kernel puts them above bottom floats). This is an invasive package
% which rewrites many portions of the LaTeX2e float routines. It may not work
% with other packages that modify the LaTeX2e float routines. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/sttools/
% Documentation is contained in the stfloats.sty comments as well as in the
% presfull.pdf file. Do not use the stfloats baselinefloat ability as IEEE
% does not allow \baselineskip to stretch. Authors submitting work to the
% IEEE should note that IEEE rarely uses double column equations and
% that authors should try to avoid such use. Do not be tempted to use the
% cuted.sty or midfloat.sty packages (also by Sigitas Tolusis) as IEEE does
% not format its papers in such ways.





% *** PDF, URL AND HYPERLINK PACKAGES ***
%
%\usepackage{url}
% url.sty was written by Donald Arseneau. It provides better support for
% handling and breaking URLs. url.sty is already installed on most LaTeX
% systems. The latest version can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/misc/
% Read the url.sty source comments for usage information. Basically,
% \url{my_url_here}.





% *** Do not adjust lengths that control margins, column widths, etc. ***
% *** Do not use packages that alter fonts (such as pslatex).         ***
% There should be no need to do such things with IEEEtran.cls V1.6 and later.
% (Unless specifically asked to do so by the journal or conference you plan
% to submit to, of course. )


% correct bad hyphenation here
\hyphenation{op-tical net-works semi-conduc-tor}

\usepackage[pdftex]{graphicx}

\begin{document}



\DeclareGraphicsExtensions{.pdf,.jpeg,.png,.jpg}

\newenvironment{figura}
  {\def\@captype{figure}}
  {}
\makeatother
%
% paper title
% can use linebreaks \\ within to get better formatting as desired
\title{Exploiting TCP Vegas' Algorithm to Improve Real-Time Multimedia Applications}


% author names and affiliations
% use a multiple column layout for up to three different
% affiliations
\author{\IEEEauthorblockN{Michele Massaro, Claudio E. Palazzi, Armir Bujari}
\IEEEauthorblockA{Department of Mathematics\\
University of Padua\\
Padua, Italy\\
Email: michele.massaro@me.com, cpalazzi@math.unipd.it, abujari@math.unipd.it}}

% conference papers do not typically use \thanks and this command
% is locked out in conference mode. If realizereally needed, such as for
% the acknowledgment of grants, issue a \IEEEoverridecommandlockouts
% after \documentclass

% for over three affiliations, or if they all won't fit within the width
% of the page, use this alternative format:
%
%\author{\IEEEauthorblockN{Michael Shell\IEEEauthorrefmark{1},
%Homer Simpson\IEEEauthorrefmark{2},
%James Kirk\IEEEauthorrefmark{3},
%Montgomery Scott\IEEEauthorrefmark{3} and
%Eldon Tyrell\IEEEauthorrefmark{4}}
%\IEEEauthorblockA{\IEEEauthorrefmark{1}School of Electrical and Computer Engineering\\
%Georgia Institute of Technology,
%Atlanta, Georgia 30332--0250\\ Email: see http://www.michaelshell.org/contact.html}
%\IEEEauthorblockA{\IEEEauthorrefmark{2}Twentieth Century Fox, Springfield, USA\\
%Email: homer@thesimpsons.com}
%\IEEEauthorblockA{\IEEEauthorrefmark{3}Starfleet Academy, San Francisco, California 96678-2391\\
%Telephone: (800) 555--1212, Fax: (888) 555--1212}
%\IEEEauthorblockA{\IEEEauthorrefmark{4}Tyrell Inc., 123 Replicant Street, Los Angeles, California 90210--4321}}




% use for special paper notices
%\IEEEspecialpapernotice{(Invited Paper)}




% make the title area
\maketitle


\begin{abstract}
%\boldmath
Computer-centered services and broadband wireless connectivity have boosted the demand for delivery of multimedia-based entertainment from the Internet to
in-house wireless appliances. In this context, rich-media applications can be supported by a variety of protocols, each sharing the same bottleneck,
affecting one another's performance. Indeed, in current systems, real-time applications (e.g., video streaming, online games) suffer
from delays caused by the interference of elastic, best-effort (e.g., TCP-based download sessions) traffic. In this paper we propose a solution to this
problem, addressed by deploying a Vegas-like congestion control algorithm at the home gateway, requiring no client-side modification.

\end{abstract}
% IEEEtran.cls defaults to using nonbold math in the Abstract.
% This preserves the distinction between vectors and scalars. However,
% if the conference you are submitting to favors bold math in the abstract,
% then you can use LaTeX's standard command \boldmath at the very start
% of the abstract to achieve this. Many IEEE journals/conferences frown on
% math in the abstract anyway.

\textbf{\textit{Access Point, Home Network, Online Game, Vegas, Wireless}}

% For peer review papers, you can put extra information on the cover
% page as needed:
% \ifCLASSOPTIONpeerreview
% \begin{center} \bfseries EDICS Category: 3-BBND \end{center}
% \fi
%
% For peerreview papers, this IEEEtran command inserts a page break and
% creates the second title. It will be ignored for other modes.
\IEEEpeerreviewmaketitle



\section{Introduction}
% no \IEEEPARstart
In no time, the Internet has grown from an interesting distraction into an essential part of our everyday life. Broadband access technology has grown considerably both for entertainment and
for communication, leading to a demand for an improved networking support able to satisfy the requirements of heterogeneous traffic flows. A representative example in this category are
TCP-based elastic flows (e.g., download) and emerging UDP-based real-time ones (e.g., video stream, online games etc.).

In this context, the coexistence of elastic and real-time network traffic presents severe issues particularly affecting the latter. The main problem derives from the nature of classic TCP
protocols, which are loss-based; continually probing the shared channel in order to increase the transfer speed until some loss occurs. This growth phase is succeeded by a slow down phase,
where the flow starts to grow its sending speed again, and these phases are interleaved in a cyclic fashion.

This \emph{modus operandi} cause the queues to fill along the channel, leading to an increase of the per-packet delivery time~\cite{game1, game2}. Even if this does not represent a major
issue for elastic applications, it causes a significant decrease of the quality of service for real-time applications~\cite{game3, game4, game5}. Addressing this issue, delay-based TCP
congestion protocols employ packet RTT rather than losses to prevent congestion. In this context, TCP Vegas is the main candidate~\cite{vegas1}; continually monitoring the packet queueing
times and shown to lead to a better quality for UDP services.

However, TCP Vegas cannot be used in a channel shared by loss-based protocols due to the aggressiveness of the latter in getting more and more bandwidth until a loss event happens, thus
capturing almost all the available bandwidth from delay-based flows. The only way to employ TCP Vegas in practice would be to completely dismiss all loss-based TCP versions, changing the
protocol of every client and server connected to the Internet. Needless to say, this is not a feasible option.

In this paper, we show how to practically exploit the benefits of delay-based protocols, intervening only in the user's Access Point (AP). As a result of this, elastic applications achieve
high data throughput, while real-time application maintain a low latency. The AP is enhanced with an algorithm that automatically limits TCP flows when the channel is near to the saturation
(like TCP Vegas), avoiding long queues and packet loss while keeping the TCP-based flows at a data rate level which corresponds to a full utilization of the available bandwidth.

The rest of the paper is organized as follows. In Section II we discuss the state of the art relevant to this domain, while in Section III we present our solution in detail. Section IV
provides an overview of the simulation environment and comparison settings, while in Section V and Section VI we discuss the experimentation outcome. Finally, Section VII concludes this
paper.

\section{Related Works}

The problem we are addressing is not new and solutions have been proposed to avoid the latency increase incurred by TCP New Reno's congestion control. As already stated above, the problem
resides in the protocol itself, this to say that one solution would be to switch from the current protocol to a delay-based one, Vegas-like. Indeed TCP Vegas is able to detect the congestion
in advance using the RTT fluctuation of the packets. Simply said, it increases the transfer speed when the delay is under an $\alpha$ threshold and decreases it when the delay is over
$\beta$ ($\alpha$ \textless $\beta$). In this way, it is not necessary to lose a packet in order to detect congestion, because it can be detected before it happens. Clearly this also avoids
the creation of bottleneck queues and corresponding queuing delays that would harm any real-time application.

Unfortunately, TCP Vegas flows cannot coexist with loss-based ones, e.g., generated by TCP New Reno and other classic real life TCP versions; loss-based flows cause congestion by their nature,
and delay-based ones detect it as an imminent congestion, slowing down their transfer rate. The result is that loss-based flows will occupy almost all the channel~\cite{vegas2, sap1}.
This incompatibility with legacy protocols made Vegas hardly applicable.

Instead, a solution that would not require a modification of Internet protocols was proposed in~\cite{sap1,sap2} and named Smart Access Point with Low Advertised Window (SAP-LAW). Basically,
this solution leverages on the ability of the Access Point to monitor all traffic passing through and by appropriately modifying the advertised window of TCP-based flows it prevents them
from exceeding their fair bandwidth share.

The algorithm detects the ongoing UDP traffic, and computes the available bandwidth, as well as the corresponding appropriate advertised window, for each flow through (1) (three flows in
the example).

\begin{equation}\label{first}
\begin{split}
&maxTCPrate_i(t)=\frac{(C-UDPtraffic(t))*RTT_i}{a_1+a_2+a_3}\\
&a_1=\frac{RTT_1}{avg.RTT_{min}}, a_2=\frac{RTT_2}{avg.RTT_{min}}, a_3=\frac{RTT_3}{avg.RTT_{min}} \\
\end{split}
\end{equation}

This avoids the classic TCP's congestion window fluctuations, stabilizing it to a computed value. Moreover, the absence of congestion alleviates delay problems for UDP packets, allowing the
user to enjoy interactive, real-time services while concurrent elastic applications still achieve high throughputs.

However, this proposal is limited as it requires an \emph{a priori} knowledge of the bottleneck capacity and the RTT of each flow; these parameters may not be always known or correctly computed
or even stable enough to be used in a timely fashion.

Similar in spirit, even it has been proposed in the context of multi-hop wireless networks, is Gateway Adaptive Pacing (GAP)~\cite{gap1, mhop-not-gap}. GAP adds an artificial delay between
each packet, based on continuous measurements of the network. In this way the interarrival time decrease, but so does even the throughput of TCP flows, thus finding scarce applicability in
the regular one-hop case.

\section{VoAP}
Our goal is to create a solution that could reach a similar performance trend to SAP-LAW, without requiring the \emph{a priori} information needed by SAP-LAW. At the same time, we want
to avoid any need for changing the network protocols of the devices connected to the network (with the only exception of the Access Point). The algorithm is designed mainly for the wireless
home scenario, where the main bottleneck is represented by the wireless component; however it was kept generic, and it should work even in a more general or wired environment.

Like SAP-LAW, our algorithm is designed to be deployed on an Access Point, so as to be able to monitor all the network traffic in real-time. To not use the additional information on
bottleneck capacity and RTTs as done by SAP-LAW, we have taken inspiration from TCP Vegas' congestion control algorithm. From here the name of our algorithm: Vegas over Access Point (VoAP).

The main idea at the basis of VoAP is to monitor all the TCP flows that pass through the AP and measure how long packets remain in its queue before actually being transmitted over the
wireless channel. When this time is below an $\alpha$ threshold it means that the channel is quite free, thus allowing the TCP-based flows to increase their transfer speed without the risk
of causing congestion/queuing delays; instead, when the time is over the $\beta$ threshold, the channel is saturating, and the TCP flows' transmissions should be slowed down as they are not
transmitting at higher rates, they are just building up queues.

The increase of the TCP's rate is regulated by its own congestion avoidance protocol, whereas to decrease it we use the advertised window already present in the header of regular ACKs.
Therefore, any TCP-based flow transmitted in the considered wireless home, regardless of its congestion window flavor, will be limited in its regular growth if and only if it is detected
to cause congestion in the AP. This is an appropriate behavior as higher transmission rates would not correspond to higher receiving rates but only to higher queuing delay.
Furthermore, as our solution can only limit the TCP's data rate, we do not have a negative impact on other flows present in the Internet core. Finally, as VoAP is applied to all and only
the TCP-based flows passing through the considered Access Point, we do not incur the risk to have an excessive limitation of the congestion window caused by the aggressive behavior of
other congestion control variants as original TCP Vegas does.

To allow a fast initial growth (slow start) the algorithm is not applied below a packet threshold of the congestion window (10 packets) and the flow is left free until it exceeds for the
first time the $\beta$ threshold; at that point, the algorithm intervenes enforcing the limitation through appropriate modifications of the advertised window, thus decreasing the flow speed
until the delay drops under $\beta$.

When the delay stay between $\alpha$ and $\beta$, the advertised window remains stable, preventing the flow growth, since the channel is almost saturated. If the channel become free, the
delay drops under the $\alpha$ threshold, so the speed is increased again.

The data are collected for a period of time \emph{T}, where the number of flows and their delays are checked and acted upon accordingly. Every increment or decrement action is per unit, so as to avoid excessive fluctuations, thus there can be at most \emph{1/T} changes of the advertised window per second. After this, the timers are reset and the delay sampling restarts. 
%In this way we are sure that the collected data are always fresh, and that they cannot be compromised by previous sampling. 
Furthermore, the time range T is needed to observe whether a flow is active or not, and split the bandwidth in a fair way; it is therefore necessary for T to be small enough to not waste bandwidth on a non-active flow, but also big enough to allow all active flows to transmit at least one packet.

The detailed flow chart of the algorithm can be seen in the Figure~\ref{voap}.

\begin{figure*}
\centering
\includegraphics[scale=0.30]{voap}
\caption{Flow chart of the VoAP algorithm.}
\label{voap}
\end{figure*}

\section{Simulation}

To implement the algorithm we chose the network simulator NS2~\cite{ns2}. First, it was necessary to understand in which layer the algorithm should be added, and we decided to implement it
inside the link layer, since it is directly connected to the FIFO queue of the outgoing packets. The considered scenario is described in Figure \ref{scenario}, where the \emph{W} nodes
represents remote servers in the Internet, and \emph{node\_} represent all the wireless devices connected to the AP (where VoAP is implemented). All the wired connections have a
100Mbps capacity and the wireless channel is based on IEEE 802.11g.

To make the simulation more realistic, we have considered the following flows:

\begin{table}[ht]
\caption{Network flows} % title of Table
\centering % used for centering table
\begin{tabular}{c c c c} % centered columns (4 columns)
\hline\hline %inserts double horizontal lines
Name & From & To & Type \\ [0.5ex] % inserts table
%heading
\hline % inserts single horizontal line
TCP(1) & W(3) & node\_(3) & Download (FTP) \\ % inserting body of the table
UDP(0) & BS(0) & node\_(0) & Movie Streaming \\
UDP(11) & W(1) & node\_(1) & Game Server to Client \\
UDP(12) & node\_(1) & W(1) & Game Client to Server \\
UDP(21) & W(2) & node\_(2) & Voice chat Server to Client \\
UDP(21) & node\_(2) & W(2) & Voice chat Client to Server \\ [1ex] % [1ex] adds vertical space
\hline %inserts single line
\end{tabular}
\label{table:nonlin} % is used to refer this table in the text
\end{table}

The start and stop time for each flow are described in Table \ref{table:time}.

\begin{table}[ht]
\caption{Start/Stop times} % title of Table
\centering % used for centering table
\begin{tabular}{c c c} % centered columns (4 columns)
\hline\hline %inserts double horizontal lines
Name & Start (s) & End (s) \\ [0.5ex] % inserts table
%heading
\hline % inserts single horizontal line
TCP(1) & 135 & 250 \\ % inserting body of the table
UDP(0) & 0 & 250 \\
UDP(11) & 45 & 250 \\
UDP(12) & 46 & 250 \\
UDP(21) & 90 & 250 \\
UDP(21) & 91 & 250 \\ [1ex] % [1ex] adds vertical space
\hline %inserts single line
\end{tabular}
\label{table:time} % is used to refer this table in the text
\end{table}

This scenario has been used in all the simulations, except for those with multiple TCP flows, in which we included other nodes and additional flows.
The network topology is depicted in Figure \ref{scenario}, where all the wireless nodes are at the same distance from the AP (10 meters).

\begin{figure}[h]
\centering
\includegraphics[scale=0.13]{scenario}
\caption{VoAP considered scenario.}
\label{scenario}
\end{figure}

\section{Results}

In this section we start by validating our proposal in presence of single and multiple flows exhibiting different characteristics. Several aspects of the algorithm are discussed and
contrasted with current state of the art, showing its performance trend under different performance metrics.

\subsection{One flow}

First, we tried to understand the algorithm's behaviour compared to the standard TCP New Reno, and to do so we make use of a single TCP flow in the scenario previously discussed. The $\alpha$
and $\beta$ thresholds have been set to 5ms and 15ms respectively, and the time range T has been set to 200ms seconds.

Figure~\ref{bw1} shows how the TCP flow behaviour goes from the standard sawtooth shape to a smoother one, with slightly lower peaks but with a higher number of transferred packets. The
lower peaks avoid queuing delays at the AP, allowing to reach lower overall delays for UDP packets, as confirmed by Figure~\ref{game}, where the peaks relative to the TCP congestion are
almost absent. This increased stability can be further noticed by monitoring the jitter, e.g., of the video stream one, depicted in Figure~\ref{jitter}, where the peaks are reduced by
a factor of 2. In Figure~\ref{bw1} we can also notice that the slow start phase is not affected by the algorithm, indicating that the discussed delayed activation of VoAP leads to the desired
result.

All the UDP flows in the scenario experienced a lower delay and jitter as expected, and the benefits for the TCP flow does not only concern the stability, but also the amount of transferred
data. To understand the real improvement we counted the TCP flow's ACKs: with New Reno we reached 181 MB of transferred data, and with VoAP we reached 222 MB, leading to an increase of
about 22\%.

\begin{figure}[h]
\centering
\includegraphics[scale=0.15]{bw1}
\caption{Bandwidth comparison between New Reno (left) and VoAP (right).}
\label{bw1}
\end{figure}

\begin{figure}[h]
\centering
\includegraphics[scale=0.15]{game}
\caption{Game packet inter-arrival comparison between New Reno (left) and VoAP (right).}
\label{game}
\end{figure}

\begin{figure}[h]
\centering
\includegraphics[scale=0.15]{jitter}
\caption{Video jitter comparison between New Reno (left) and VoAP (right).}
\label{jitter}
\end{figure}

\subsection{Multiple TCP flows}

The algorithm behaviour in a multi-TCP-flow scenario is fundamental to understand whether the bandwidth is equally distributed among users sharing the same channel. To this end, when active
TCP flows reach the stable interval between the $\alpha$ and $\beta$ thresholds, the sum of the advertised windows indicate how many packets can be in transit without exceeding the channels
capacity. This information is used to assign a fair share of bandwidth to every TCP flow.

In order to avoid excessive fluctuation, the bandwidth share is computed in a smoothed way, i.e., the average between the old and the new value at every T.
The result can be seen in Figure~\ref{diffTime}, where three TCP flows were started in three different moments in time, this to show how the bandwidth is equally shared between flows that
are already exploiting the wireless channel and new starting ones.

Obviously, even if the flows started at the same time the result would have been the same; we also made additional tests employing five TCP flows, and each one succeed to obtain an equal
share of the bandwidth.

\begin{figure}[h]
\centering
\includegraphics[scale=0.11]{diffTime}
\caption{Bandwidth of 3 TCP flows using VoAP.}
\label{diffTime}
\end{figure}

\subsection{Thresholds}

In the current version of our algorithm, $\alpha$ and $\beta$ thresholds are static values with the higher one corresponding to the maximum amount of queuing time we are ready to suffer.
Their choice entails a different behaviour of the algorithm, because $\alpha$ and $\beta$ denote how short the queue must be, decision that has an impact on both the UDP packet latency and
the TCP transfer rate. Due to the importance of these variables, we have tested different values, where the $\beta$ threshold varied between 10ms and 20ms.

Adopting a low threshold, the maximum queue time is reduced, so the UDP packet latency become lower; however, in this way the TCP flow is penalized, because its advertised window becomes
smaller, leading to a lower throughput. Employing a high threshold instead, allows the TCP flow to increment the number of outgoing packet, leading to a higher bandwidth, penalizing UDP
packets that will experience a higher latency. The comparison between the two instances can be seen in Figure~\ref{soglie}, where the two borderline cases are measured with the TCP bandwidth
and the UDP game interarrival time.

It is noteworthy to point out that in both the cases, the latency and the bandwidth are noticeably better than what is obtained with New Reno. The instance 5-15ms is a compromise between the
two behaviours, and for this reason it has been chosen as the default range.

\begin{figure}[h]
\centering
\includegraphics[scale=0.16]{soglie}
\caption{Comparison between $\beta$=0.010s (left) and $\beta$=0.020s (right).}
\label{soglie}
\end{figure}

\section{Comparison with SAP-LAW}

Since both SAP-LAW and VoAP use the AP as control center, we run some trials employing the same network deployment as before contrasting both the approaches. Figure~\ref{sap} shows how the
TCP flows' bandwidth and the UDP game interarrival time change in both schemes. The bandwidth is improved by VoAP, both in terms of quantitative value and stability. The interarrival time
results slightly lower using SAP-LAW; yet its value is low enough to not jeopardize the performance of the application and, conversely from SAP-LAW, VoAP achieves this result without the
need of prior information about bottleneck capacity and the flows' RTT.

\begin{figure}[h]
\centering
\includegraphics[scale=0.16]{sap}
\caption{Bandwidth (above) and interarrival (below) comparison between SAP-LAW (left) and VoAP (right).}
\label{sap}
\end{figure}

\section{Conclusions}

We have presented and discussed a solution, named VoAP, addressing the coexistence problem between TCP and UDP flows. Our proposal provides to both kinds of flow the possibility to reach
high throughput and low per-packet delay.
We used NS2 to demonstrate the effectiveness of the algorithm in significantly improving the network performance of heterogeneous flows in a realistic wireless home configuration.
The goal has been achieved through the implementation of a TCP Vegas-inspired algorithm implemented in the Access Point. Therefore, our solution works in a transparent way for the user
and without the need to modify any client, server or Internet router.

% trigger a \newpage just before the given reference
% number - used to balance the columns on the last page
% adjust value as needed - may need to be readjusted if
% the document is modified later
%\IEEEtriggeratref{8}
% The "triggered" command can be changed if desired:
%\IEEEtriggercmd{\enlargethispage{-5in}}

% references section

% can use a bibliography generated by BibTeX as a .bbl file
% BibTeX documentation can be easily obtained at:
% http://www.ctan.org/tex-archive/biblio/bibtex/contrib/doc/
% The IEEEtran BibTeX style support page is at:
% http://www.michaelshell.org/tex/ieeetran/bibtex/
%\bibliographystyle{IEEEtran}
% argument is your BibTeX string definitions and bibliography database(s)
%\bibliography{IEEEabrv,../bib/paper}
%
% <OR> manually copy in the resultant .bbl file
% set second argument of \begin to the number of references
% (used to reserve space for the reference number labels box)
\begin{thebibliography}{1}

\bibitem{game1}
G. Marfia, M. Roccetti, ``TCP At Last: Reconsidering TCP's Role for Wireless Entertainment Centers at Home'', IEEE Transactions on Consumer Electronics 56(4), 2010.

\bibitem{game2}
C. E. Palazzi, G. Pau, M. Roccetti, M. Gerla, ``In-Home Online Entertainment: Analyzing the Impact of the Wireless Mac-Transport Protocols Interference'', in Proc. of IEEE International Conference on Wireless Networks, Communications and Mobile Computing (WIRELESSCOM), Maui, HI, USA, 2005.

\bibitem{game3}
Arnaud Kaiser, Dario Maggiorini, Nadjib Achir, Khaled Boussetta, ``On the Objective Evaluation of Real-Time Networked Games'', in Proc. of GLOBECOM 2009, Honolulu, HI, USA, 2009.

\bibitem{game4}
Jose Saldana et al., ``The Effect of TCP Variants on the Coexistence of MMORPG and Best-Effort Traffic'', in Proc. of ICCCN 2012, Munich, Germany, 2012.

\bibitem{game5}
Sergei Gorlatch, Alexander Ploss, ``Towards a Scalable Real-Time Cyberinfrastructure for Online Computer Games'', in Proc. of ICPADS 2009, Shenzhen, China, 2009.


\bibitem{vegas1}
S. Low, L. Peterson, L. Wang, ``Understanding TCP Vegas: Theory and Practice'', Princeton University, Princeton, New Jersey, 2000.

\bibitem{vegas2}
L. S. Brakmo, L. L. Peterson, ``TCP Vegas: End to End Congestion Avoidance on a Global Internet'', IEEE Journal on Selected Areas in Communications 13(8), 2002.

\bibitem{sap1}
C. E. Palazzi, S. Ferretti, M. Roccetti, G. Pau, M. Gerla, ``What's in That Magic Box? The Home Entertainment Center's Special Protocol Potion, Revealed'', IEEE Transactions on Consumer Electronics 52(4), 2006.

\bibitem{sap2}
C. E. Palazzi, N. Stievano, M. Roccetti, ``A Smart Access Point Solution for Heterogeneous Flows'', in Proc. of the International Conference on Ultra Modern Telecommunications and Workshops  (ICUMT), St. Petersburg, Russia, 2009.

%\bibitem{paper4}
%U. Hengartner, J. Bolliger, T. Gross, ``TCP Vegas Revisited'', in Proc. of IEEE INFOCOM, Tel Aviv, Israel, 2000.

\bibitem{gap1} S. M. ElRakabawy, A. Klemm, C. Lindemann, ``Gateway Adaptive Pacing for TCP Across Multihop Wireless Networks and the Internet'', in Proc. of ACM International Symposium on Modeling Analysis and Simulation of Wireless and Mobile Systems (MSWiM'06), Torremolinos, Spain, 2006.

\bibitem{mhop-not-gap} K. Kim, D. S. Niculescu, S. Hong, ``Coexistence of VoIP and TCP in Wireless Multihop Networks'', IEEE Communications Magazine 47(6), 2009.

\bibitem{ns2}
The Network Simulator 2, ``NS-2'' [ONLINE]. Available: http://www.isi.edu/nsnam/ns
\end{thebibliography}
% that's all folks
\end{document}


